DUST Search - The wait for EVE:fps (PHOENIX)

Vell0cet wrote:

Cat Merc wrote:

Vell0cet wrote:

Pokey Dravon wrote:

Vell0cet wrote:

It really depends on what they mean by starting from scratch. If they're actually starting from 0--opening a blank text editor and starting from a blank screen, then we're looking at years before there is anything playable (pre-alpha), and probably a couple more after that to have something that's got most of the worst bugs worked out.

Well, they're starting with the Unreal 4 Engine which has a pretty solid baseline setup for a number of games, FPS included. So a lot of the very very basic **** is already done, it's just a matter of modifying it and optimizing the engine so it can run properly and look the way they want it to.

From scratch as in, building an entire engine from the ground up? God no.

From scratch as in not using existing DUST code but utilizing what Unreal 4 has to offer? Yes. (Thank god)

If they're not using any of the existing DUST code, I'm pretty sure that would guarantee this new game never gets shipped. I agree they should reuse as much from other developers as possible (like the Unreal stuff) and not modify/overcomplicate things that work, but if they're planning on a similar skill point system (just as a random example) then they'd be crazy not to port over the pieces that work from the existing DUST code. A lot of the messiness in our code represents bugs that got fixed, each one could be days of someone at CCP's life to identify the edge case, document it, reproduce it, find where in the source the problem is occurring and then writing a fix for it.

Flat out deleting that stuff is throwing all of that work away. It's the biggest mistake a software company can make. The correct approach is to study the existing code, understand where the edge cases come from, bring over/port the parts that work, and refactor the ones that don't.

DUST has a severe case of software rot.
I'm sure there are things they can salvage, but it's best if they don't touch most of it with a ten foot pole.

With respect, I think you're completely wrong. How can they possibly learn from their mistakes that way? If you bring in a new team of people, what's to stop them from repeating all of the same mistakes if they don't learn from the past? Why should we expect the development process to be any faster this time around than last time? I agree there's probably tons of rot in DUST's code, but it's critical to understand what went wrong and why to have any hope of doing better the second time around.

They call me the Monkey - I like to jump off sh** and piss RE's all over your tank!


Author	Thread Statistics \| Show CCP posts - 0 post(s)
Monkey MAC Rough Riders.. 3	Posted - 2016.02.08 13:16:00 - [1] - Quote Vell0cet wrote: Cat Merc wrote: Vell0cet wrote: Pokey Dravon wrote: Vell0cet wrote: It really depends on what they mean by starting from scratch. If they're actually starting from 0--opening a blank text editor and starting from a blank screen, then we're looking at years before there is anything playable (pre-alpha), and probably a couple more after that to have something that's got most of the worst bugs worked out. Well, they're starting with the Unreal 4 Engine which has a pretty solid baseline setup for a number of games, FPS included. So a lot of the very very basic ** is already done, it's just a matter of modifying it and optimizing the engine so it can run properly and look the way they want it to. From scratch as in, building an entire engine from the ground up? God no. From scratch as in not using existing DUST code but utilizing what Unreal 4 has to offer? Yes. (Thank god) If they're not using any of the existing DUST code, I'm pretty sure that would guarantee this new game never gets shipped. I agree they should reuse as much from other developers as possible (like the Unreal stuff) and not modify/overcomplicate things that work, but if they're planning on a similar skill point system (just as a random example) then they'd be crazy not to port over the pieces that work from the existing DUST code. A lot of the messiness in our code represents bugs that got fixed, each one could be days of someone at CCP's life to identify the edge case, document it, reproduce it, find where in the source the problem is occurring and then writing a fix for it. Flat out deleting that stuff is throwing all of that work away. It's the biggest mistake a software company can make. The correct approach is to study the existing code, understand where the edge cases come from, bring over/port the parts that work, and refactor the ones that don't. DUST has a severe case of software rot. I'm sure there are things they can salvage, but it's best if they don't touch most of it with a ten foot pole. With respect, I think you're completely wrong. How can they possibly learn from their mistakes that way? If you bring in a new team of people, what's to stop them from repeating all of the same mistakes if they don't learn from the past? Why should we expect the development process to be any faster this time around than last time? I agree there's probably tons of rot in DUST's code, but it's critical to understand what went wrong and why to have any hope of doing better the second time around. True that doesn't mean you have to use code in order to learn from it. DUST suffered from of developer problems because of the way some of the debs were locked out of the system. Which we don't want again. However there will be salvageable things like Art assets that could be reused with little to no effort, but for things like damage calculation, overheat mechanics, fitting fragmentation it's better to start from scratch with the old code in mind, then to use the old code, to much temptation to hack it in. They call me the Monkey - I like to jump off sh and piss RE's all over your tank! Monkey Mac - Forum Warrior Lvl 3